home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / t3_1 / doc.lha / documentation / manual / object.mss < prev    next >
Text File  |  1987-06-30  |  11KB  |  270 lines

  1. @part[OBJECT, root "TMAN.MSS"]  @Comment{-*-System:TMAN-*-}
  2. @chap[Objects]
  3.  
  4.  
  5. @Tau[] is an @i[object-oriented] language.  @Tau[] programs
  6. are concerned for the most part with creating and manipulating
  7. @iix[objects], which represent all data, and form the
  8. currency of computation in @Tau[].  Particular objects are defined not
  9. by bit patterns or by addresses within a computer but rather by their
  10. behavior when called or when passed to procedures which manipulate them.
  11.  
  12. Objects are obtained most primitively through the use of @tc[QUOTE]
  13. (page @pageref[QUOTE]), @tc[LAMBDA] (page @pageref[LAMBDA]), and @tc[OBJECT]
  14. (page @pageref[OBJECT]) special forms, and less primitively by calling
  15. procedures defined in the standard environment, e.g. @tc[CONS] and
  16. @tc[COMPOSE], which create new objects or return existing ones.  (An
  17. implementation of @Tau[] would presumably define many such procedures
  18. using more primitive object constructors; for example, @tc[COMPOSE]
  19. might be defined by a @Tau[] program which employs @tc[LAMBDA] to
  20. construct the composed procedure.  Thus the question of what kinds of
  21. objects are truly primitive and which are not is left unanswered by this
  22. manual.)
  23.  
  24.  
  25. @section[Literals]
  26.  
  27. As described in section @ref[CoreLanguageSection], some expressions
  28. evaluate @qu"to themselves" or to copies of themselves.  These include
  29. numbers, strings, and characters, and are called
  30. @i[self-evaluating literals.]  However, some expressions, lists and
  31. symbols in particular, do not evaluate to themselves.  When an
  32. expression yielding a particular constant value is required,
  33. it is necessary to use @tc[QUOTE].  Self-evaluating literals
  34. and quoted constants are called @iix[literals].
  35.  
  36. Although not all objects have external representations, some objects
  37. which do have external representations have undefined evaluation
  38. semantics.  These include vectors (section @ref[VectorsSection]) and the
  39. empty list.  @tc[QUOTE] must also be used to obtain these values as
  40. constants.
  41.  
  42. @info[NOTES="Special form"]
  43. @desc[@el[](QUOTE @i[object]) @yl[] @i[object]]
  44. Yields @i[object].  The @i[object] is not evaluated; thus @tc[QUOTE]
  45. provides a literal notation for constants.
  46. @begin[ProgramExample]
  47. (QUOTE A)          @ev[]  A
  48. (QUOTE (A B))      @ev[]  (A B)
  49. (QUOTE (+ X 8))    @ev[]  (+ X 8)
  50. (QUOTE (QUOTE A))  @ev[]  (QUOTE A)
  51. @end[ProgramExample]
  52. Since @tc[QUOTE] is used so frequently, an abbreviated external syntax
  53. is provided for @tc[QUOTE] forms: @tc['@i[object]] is an alternative
  54. external representation for the list @tc[(QUOTE @i[object])].
  55. @tindex[']
  56.   @begin[ProgramExample]
  57. 'A          @ev[]  A
  58. '(A B)      @ev[]  (A B)
  59. '(QUOTE A)  @ev[]  (QUOTE A)
  60. ''A         @ev[]  (QUOTE A)
  61.   @end[ProgramExample]
  62. Objects returned by literal expressions are read-only; they should not
  63. be altered using @tc[SET] or any other side-effecting form.
  64. @EndDesc[QUOTE]
  65.  
  66.  
  67. @section[Procedures]
  68.  
  69. A @i[procedure]@index[procedures] (or @i[routine]@index[routines])
  70. is any object which may be called.  Ordinarily, a procedure is called
  71. as a result of the evaluation of a @i[call] (page @pageref[CallSemantics]).
  72. The most primitive mechanism for creating procedures is the
  73. @tc[LAMBDA] special form.
  74.  
  75. @IndexEntry[key = "Functions", text = "Functions, @i<see> Procedures"]
  76.  
  77. @dc{ Talk about why procedures are important; first-class citizenship;
  78. surprising roles; etc. ...? }
  79.  
  80. @AnEquivE[Tfn="LAMBDA",Efn="CLOSURE"]
  81. @info[NOTES="Special form",EQUIV="FUNCTION"]
  82. @desc[@el[](LAMBDA @i[variables] . @i[body]) @yl[] @i[procedure]]
  83. A @tc[LAMBDA]-expression evaluates to a procedure.
  84. When the procedure is called, the @i[variables]
  85. are bound to the arguments to the call, and the @i[body], an implicit
  86. block, is evaluated.  The call yields the value of the last form in the
  87. @i[body].
  88.  
  89. @begin[ProgramExample]
  90. ((LAMBDA (X Y) (LIST Y X)) 7 'FOO)  @ev[]  (FOO 7)
  91. @end[ProgramExample]
  92.  
  93. If @i[variables] is not a proper list, but ends in a symbol @i[x], then
  94. the variable @i[x] will be bound to a list of the arguments beginning at
  95. the position corresponding to @i[x].
  96.  
  97. @begin[ProgramExample]
  98. ((LAMBDA (X . Y) (LIST Y X)) 7 'FOO 'BAZ)  @ev[]  ((FOO BAZ) 7)
  99. ((LAMBDA Y Y) 7 'FOO 'BAZ)                 @ev[]  (7 FOO BAZ)
  100. @end[ProgramExample]
  101.  
  102. If any @i[variable] is @tc[()] instead of a symbol, then the
  103. corresponding argument in a call is ignored.  @dc{ ref @tc[IGNORE]! }
  104.  
  105. @i[Scoping:]@index[scope]@index[lexical scoping]
  106. The values of the bound variables are apparent only in code lexically
  107. contained in the body of the @tc[LAMBDA]-expression, and not to routines
  108. @i[called] from the body.  That is, like SCHEME and ALGOL and unlike
  109. most Lisp dialects, @tau[] is a lexically scoped language, not a dynamically
  110. scoped language.
  111.  
  112. @i[Closure:]@index[closure]
  113. @dc{ Rewrite this paragraph. }
  114. The @i[procedure] is said to be a @iix[closure] of the
  115. @tc[LAMBDA]-expression in the current lexical environment.  That is, when
  116. @i[procedure] is called, the @i[body] is evaluated in an environment
  117. which is the same as that in which the @tc[LAMBDA]-expression was
  118. evaluated, augmented by the bindings of the @i[variables].  For example,
  119. if @tc[Z] is mentioned in the @i[body], and it is not one of the
  120. @i[variables], then it refers to whatever @tc[Z] was in scope when the
  121. @tc[LAMBDA]-expression was evaluated, @i[not] (necessarily)
  122. to the the variable @tc[Z] that is in scope when @i[procedure] is called.
  123. @EndDesc[LAMBDA]
  124.  
  125.  
  126. @section[Object identity]
  127.  
  128. Every object has @i[identity,] in the sense that one may determine
  129. whether two given values are the same object.
  130. @index[Equality predicates]
  131. @index[Identity]
  132.  
  133. In the following:
  134.   @begin[ProgramExample]
  135. (DEFINE A (LIST 'P 'Q))
  136. (DEFINE B (LIST 'P 'Q))
  137.   @end[ProgramExample]
  138. there is no way (other than @tc[EQ?]) to distinguish the two objects
  139. which are the values of @tc[A] and @tc[B].  Nonetheless, since @tc[LIST]
  140. is defined to return a new object each time it is called, the two
  141. objects are distinct; and indeed, a side-effect to one object will not affect
  142. the value of the other:
  143.   @begin[ProgramExample]
  144. (SET (CAR A) 'R)
  145. A  @ev[]  (R Q)
  146. B  @ev[]  (P Q)
  147.   @end[ProgramExample]
  148.  
  149. Some system procedures and special forms create new objects, others
  150. return objects which already exist.  In some cases, it is not defined
  151. which of the two happens; it is only guaranteed that some object with
  152. appropriate characteristics is returned.  For example, @tc[CONS] creates
  153. new objects; @tc[QUOTE] expressions yield pre-existing constant objects;
  154. and numerical routines such as @tc[+] may or may not create new numbers.
  155.  
  156. The @tc[EQ?] predicate primitively determines object identity.
  157.  
  158. @desc[@el[](EQ? @i[object1 object2]) @yl[] @i[boolean]]
  159. Returns true if @i[object1] and @i[object2] are identically the same
  160. object.  @tc[EQ?] is the @i[finest] comparison predicate for
  161. objects, in the sense that if @tc[EQ?] cannot distinguish two objects,
  162. then neither can any other equality predicate.  @dc{ what the??? }
  163. @EndDesc[EQ?]
  164.  
  165. @desc[@el[](NEQ? @i[object1 object2]) @yl[] @i[boolean]]
  166. @tc[NEQ?] is the logical complement of @tc[EQ?].
  167.   @begin[TEG]
  168. (NEQ? @i[object1 object2]) @ce[] (NOT (EQ? @i[object1 object2]))
  169.   @end[TEG]
  170. @EndDesc[NEQ?]
  171.  
  172. Uniqueness of literals (other than symbols and characters) isn't defined
  173. in general.  For example,
  174.   @begin[ProgramExample]
  175. (EQ? '(A B C) '(A B C))
  176.   @end[ProgramExample]
  177. may yield either true or false, depending on the implementation.
  178. Two similar-looking literal expressions in different places
  179. may or may not yield distinct objects.
  180.  
  181. However, a given literal expression will always yield the same object
  182. each time it is evaluated. @dc{ forward reference }
  183.   @begin[ProgramExample]
  184. (LET ((F (LAMBDA () '(A B C)))) (EQ? (F) (F)))  @yl[]  @r[true]
  185.   @end[ProgramExample]
  186.  
  187.  
  188. @section[Symbols]
  189. @label[symbols section] @Comment{ref. semantics chapter}
  190.  
  191. @iix[Symbols] are named objects which have wide applicability as
  192. tokens and identifiers of various sorts.  Symbols are uniquely
  193. determined by their names, and have a convenient external syntax
  194. by which they may be obtained.
  195.  
  196. Uniqueness of symbols @i[is] defined:
  197.   @begin[ProgramExample]
  198. (EQ? 'FOO 'FOO)  @ev[]  @r[true]
  199.   @end[ProgramExample]
  200.  
  201. @dc{ Give details of external representation.  Should we avoid defining
  202. the \ syntax here?  It really seems extraneous, and surely it shouldn't
  203. be encouraged. }
  204.  
  205. @info[NOTES="Type predicate",EQUIV="SYMBOLP"]
  206. @desc[(SYMBOL? @i[object]) @yl[] @i[boolean]]
  207. Returns true if @i[object] is a symbol.
  208. @EndDesc[SYMBOL?]
  209.  
  210. See also @tc[SYMBOL->STRING] and @tc[STRING->SYMBOL], page
  211. @pageref[STRING->SYMBOL].
  212.  
  213.  
  214. @section[Predicates and truth values]
  215.  
  216. Conditional expressions in @Tau[] (see section
  217. @ref[ConditionalsSection]) usually involve the evaluation of a
  218. @iixs[test] expression; the object yielded by the test is then used to
  219. make a control decision, depending on whether the value is @iix[false]
  220. or @iix[true].  There is one false value; this is a distinguished object
  221. called @iix[null].  Any other value is considered to be true.  A value
  222. intended to be used in this way is called a @iixs[truth value].
  223. @index[Conditionals]
  224.  
  225. A @iixs[predicate] is any procedure which yields truth values.
  226. Predicates are typically given names which end in @tc[?],
  227. e.g. @tc[NULL?] and @tc[EQ?].  Calls to predicates are
  228. naturally used as test expressions.
  229.  
  230. An @iixs[equality predicate] is a two-argument predicate which is
  231. side-effectless and unaffected by side-effects, and acts like an
  232. equivalence relation in the mathematical sense.
  233.  
  234. @desc[@el[]NIL @yl[] @i[false]]
  235. This system variable has as its value the object @i[null.]  Null serves
  236. two distinct purposes in @Tau[]:  it is the standard false value,
  237. as returned by test expressions and tested by conditionals; and it
  238. is the @iix[empty list], a list which has no elements.  Null's external
  239. representation is @tc[()].
  240.  
  241. (Programmers with prior LISP experience should note that in most other
  242. dialects of LISP, null and the symbol @tc[NIL] are identical.  This
  243. is not the case in @tau[]: @wt['NIL @ev[] NIL], but @wt[NIL @ev[]
  244. ()], and @wt[(EQ? NIL 'NIL)] is false.)
  245. @EndDesc[NIL]
  246.  
  247. @info[IndexHack]
  248. @desc[@el[]T @yl[] @i[true]]
  249. The system variable @tc[T] has as its value a standard true value.
  250. The identity of this value is unimportant, since any non-false value
  251. is considered to be true for the purposes of tests.
  252. @EndDesc[T]
  253.  
  254.  
  255. @section[Types]
  256.  
  257. A @iixs[type] may be seen either as a collection of objects
  258. with similar behavior, or as a characteristic function for such a
  259. collection, or as the behavior characteristic of similar objects; these
  260. views are equivalent.
  261.  
  262. A @iixs[type predicate] is a predicate which is defined on all objects and
  263. whose value is not affected by any side-effects (that is, calling the
  264. type predicate on a particular object will return the same value
  265. regardless of the point at which it is called with respect to arbitrary
  266. other computations).  Type predicates are usually used to determine a
  267. given object's membership in a type.
  268.  
  269. @dc{ is more discussion in order here? ... }
  270.